When a module (e.g., executable software) is loaded into an Execution Environment (XE) for processing, an XE loader copies the module into executable memory storage. It assigns and binds an identity to the loaded module instance and sets environmental parameters within the XE. Other configuration parameters may also be set to limit or constrain the behavior of the module instance when it executes. In particular, the XE uses the assigned identity of the module instance to provide resource (e.g., file, memory, and device) access rights to an executing instance of the loaded module. When a single module is loaded as multiple executable instances into the same XE for processing a variety of issues arise.
First, the XE may need to uniquely identify each executable instance for proper run-time management (identification). Second, each instance may need to be independently authenticated (authentication). Third, each instance may need to operate with different operation parameters (configuration).
Conventionally, a few different techniques have dealt with problems arising from the first issue (identification). One technique is to use existing administrator tools that assign unique XE identities to each executable instance of the module processing in the XE. This requires manual attention by an administrator to create a separate XE identity and execution environment for each executable instance. Another technique is to let the XE manage multiple executable instances by starting each instance with the same XE identity, but in its own process executable environment. For example, in UNIX® two executable instances of a module can be started inside separate shells and forked off for separate execution. This approach may create support issues for an administrator since the identity of a particular executable instance may not be readily or easily discernable within the XE. Moreover, this approach also requires manual attention by an administrator, which increases the risk of error or subversion.
The industry generally solves problems arising from the second issue (authentication) using a variety of authentication techniques. Some techniques use internal software logic associated with the module to provide self-authentication. In some execution environments, identity is inherited from the loader and reset by the module itself using an XE-provided function, such as the UNIX® function “setuid( )” Other techniques use hidden files or keys, either within the code of the application module or in files stored in the XE or similar attached storage that provide for information needed to respond to challenge-based authentication protocols (generally called credentials) by the XE or other application services with which the application instance needs to interact.
Still other techniques use third-party services that provide authentication assurances to the XE or other applications, but these, too, usually require storage of credentials for each application instance in a manner that will allow the application to retrieve them for use. These techniques may prove sufficient for authenticating the identity of the module, but often prove cumbersome and difficult to manage when authenticating the identities of multiple executable instances of the same module. In particular, these techniques introduce significant security problems when the storage of identities and credentials (e.g., passwords or keys) on disk gives access to them to administrators or hackers who may misappropriate the use of the application's identity and credential material.
The third issue (configuration) is generally dealt with by creating separate and distinct execution environments for each executable instance of the module, such that the configuration of each module is different within each environment. Yet, each separate environment is manually maintained and monitored, which is cumbersome and prone to error because of its redundant nature.
Thus, improved techniques for loading, authenticating, and configuring behaviors of a loaded module are needed.